前言

上一篇跟各位很粗略分享了 PRD 的概念，本篇與大家說明在這次鐵人賽，我們會應用 PRD 概念做到什麼階段以及所扮演角色

內文

如同上一篇提到的，PRD 是一個幫助公司開發產品時需要的規格書。但我們只希望取 PRD 具有「確立產品規格」的屬性，讓需求可以以文字、有明確統整歸納的邏輯整理出來，因此在這邊，PRD 會稍微簡化成比較平易近人的版本。

具體會是什麼樣子呢？首先，我們不需要讓 PRD 變得像是產品規劃、驗證商業模式的這種規模，而是做到：使用者需求整理、主要使用角色盤點、流程分解、工具對應、驗收標準。

1. 使用者需求整理：需求百百種，但是要能解釋清楚、說出來，我們得依賴前人的智慧，協助我們把需求講清楚，PRD 的用途之一正是如此。
2. 主要使用角色盤點：在該需求之下，有哪些主要角色與需求相關？這個問題將能協助梳理需求，並且在盤點角色後，進行下一步 — 流程分解
3. 流程分解：得到使用角色之後，流程梳理可以讓每個重要情境都被好好涵蓋，避免有重要資訊缺漏
4. 工具對應：此指開發框架、技術選型。這個會比較需要具有軟體開發背景，但這部分我們依然可以請求生成式 AI 協助我們盡力做到
5. 驗收標準：要如何確認產出的工具能派上用場？這時候驗收標準就會是重要參考。

PRD 架構

1. 使用者需求整理

（需求要能講清楚、拆解痛點與期望）

• 痛點與期望
  • 現行方式最大的痛點是什麼？
  • 最想改善的步驟是什麼？
  • 如果有自動化工具，你希望它能做到哪些事？（排班、通知、統計…）
  • 有沒有擔心自動化會帶來什麼問題？（靈活性不足、需要學新系統）
• 需求範圍與限制條件
• 排班邏輯 / 規則

2. 主要使用角色盤點

（在需求下有哪些角色會被影響？）

• 背景與現況
  • 角色定位（例如：排班負責人、小蛋、同事、主管）

3. 流程分解

（盤點角色後，把工作情境梳理成流程）

• 背景與現況
  • 現行流程
• 溝通與確認流程（例如：目前如何確認班表？由誰審核？怎麼通知？）

4. 工具對應

（資料、系統、開發框架的考量）

• 資料與系統
  • 是否有現成的資料庫？
  • 資料存放在哪裡？
  • 是否需要跟其他系統整合？

5. 驗收標準

（如何確認工具好用？）

• 時間與成本（例如：是否能縮短排班時間？人力成本是否降低？）
• 工具是否能符合規則並正確輸出？
• 使用者是否能輕鬆上手？